Thanks for this! In my testing, this needs a couple more tweaks that I have in a local branch. Will push an update with that later tonight hopefully.

awesome, wonder what i missed :)

I don't remember merging this... 🤔

wasn't me :D

@gijsbotje Haha, all good. I have a big explanation for what I had to do in addition to this PR, but it boils down to the following:

• We should keep all our shared styles to the first .custom-control-input, so we can avoid repeating those selectors for radio and check flavors.
• As soon as we consolidate them at the top, we hit some issues with other states overriding those styles.
• The gradient-bg() mixin needs an alternative where it doesn't unnecessarily set a background-color.

There may've been a few more things. My first pass is at https://github.com/twbs/bootstrap/compare/disabled-custom-checks, but I think I have more on my other laptop at home.

Here's what I drafted for that other reply... I need to verify all this still, so trying to do that tonight. Depending on how deep into the rabbit hole I get, might punt on cleaning it up.

As I was reviewing this PR, I saw that you were effectively setting the :disabled:checked styles for radio and checkbox separately. This should be done once on the general .custom-check-input, thereby reduping that selector for the background-color.

Here's the diff for that:

diff --git a/scss/_custom-forms.scss b/scss/_custom-forms.scss
index dd844c07f..281ed2be7 100644
--- a/scss/_custom-forms.scss
+++ b/scss/_custom-forms.scss
@@ -49,6 +49,10 @@
         background-color: $custom-control-indicator-disabled-bg;
       }
     }
+
+    &:checked ~ .custom-control-label::before {
+      background-color: $custom-control-indicator-checked-disabled-bg;
+    }
   }
 }
 
@@ -108,21 +112,16 @@
     }
   }
 
-  .custom-control-input:indeterminate ~ .custom-control-label {
-    &::before {
+  .custom-control-input:indeterminate {
+    ~ .custom-control-label::before {
       @include gradient-bg($custom-checkbox-indicator-indeterminate-bg);
       @include box-shadow($custom-checkbox-indicator-indeterminate-box-shadow);
     }
-    &::after {
+    ~ .custom-control-label::after {
       background-image: $custom-checkbox-indicator-icon-indeterminate;
     }
-  }
 
-  .custom-control-input:disabled {
-    &:checked ~ .custom-control-label::before {
-      background-color: $custom-control-indicator-checked-disabled-bg;
-    }
-    &:indeterminate ~ .custom-control-label::before {
+    &:disabled ~ .custom-control-label::before {
       background-color: $custom-control-indicator-checked-disabled-bg;
     }
   }
@@ -145,12 +144,6 @@
       background-image: $custom-radio-indicator-icon-checked;
     }
   }
-
-  .custom-control-input:disabled {
-    &:checked ~ .custom-control-label::before {
-      background-color: $custom-control-indicator-checked-disabled-bg;
-    }
-  }
 }

Once I made that change, the :disabled:checked was no longer picking up the new background-color you added. Here's the before and after of applying the above diff.

Before	After

So, because of that, I needed to make additional changes to find and remove the offending background-color that was overriding your new one. Turns out, it's coming from the gradient-bg() mixin that sets a background-image gradient (if enabled) or a background-color. The latter is unnecessary in these situations. As such, I added another mixin, gradient, to only apply a background-image when gradients are enabled.

yeah sounds like a better idea to do this form .custom-check-input
I figured, since indeterminate is set at that level, I could add the disabled state there as well
but looks good to me, good luck diving into the rabbit hole 😁